电网监控系统中实时数据库的快速检索

1 引言 　　近年来，实时数据库的研究已经成为现代数据库的重要研究方向之一，在数据库的研究领域受到了极大的关注。作为工控软件的关键技术之一，实时数据库在一些实时性要求较强的系统中发挥着十分重要的作用。实时数据库适用于处理不断更新且快速变化的数据，以及具有时间限制的事务。例如在电网监控系统中，常常需要在几秒内刷新几千甚至上万种实时量和状态量，同时，为保持监控画面与现场状态的一致性，还需要刷新相应的监控画面。这就对实时数据库的检索效率提出了更高的要求。 2 影响检索效率的因素 　　在实时数据库系统中，数据的存取速度是影响检索效率的主要瓶颈之一。在对计算机硬件的性能进行分析后可以确定，硬盘的存取速度大致为100Mb/s，如果频繁的进行外存的存取操作，将会严重影响系统效率。其次是查找表的平均查找长度的影响，在大数据量的情况下，如果平均查找长度较大也会成为系统的瓶颈。同时由于数据处理的不可预知性，当某个数据的处理过程不能在规定的时间内完成时，还可能使实时数据库中的数据失效或者遗漏一些重要的数据及事件，即会引起数据处理的滞后甚至冲突。 　　当然，随着微电子技术的发展，大容量内存已经不是设想而成为事实。通过扩展内存可以把所有需要实时存取的数据放在内存中，而把实时数据库中用于决策支持的历史记录，以及其他的一些派生数据（报警记录、事故记录等）存放在外存上的关系数据库中，这在一定程度上可以缓解对速度的要求。但内存不可能无限制扩大，为此必须研究软件上的方法。 3 基于向量的检索 3．1 数据结构 在电网监控系统中实时数据库需要保存从各个测控装置采集上来的数据，用于实时监视和现场控制，并对监控点的情况进行报警和事故的判断和分析。这些数据的存储结构对查找表的平均查找长度有重要的影响。 　　根据向量（vector）检索效率比较高的特点，本文采用了向量来组织这些数据，所形成的实时数据库的存储结构如图1所示。其中，现场的每个监控点是由厂站名称、监控点类型、和监控点名称唯一确定的，每个监控点的状态则通过多个参数来描述，这些参数通常是由现场值、报警标志、报警上下限、报警死区、工作状态和一些统计量等组成。 3．2算法的实现 　　为了减小平均查找长度,该实时数据库的排序和检索可以按照如下算法实现： 　　1．厂站名称的排序和检索。根据厂站的数量一般都相对较少的特点，构造如下集合间的映射： map：{厂站名称} {向量下标} 其中，厂站名称为键，向量下标为值，于是就可由厂站名称直接得到该向量元素的下标，从而查找到该厂站。 　　2．监控点类型和监控点名称的排序和检索。针对监控点类型和监控点的名称的数量相对都比较大的特点，采用hash表对它们进行排序。为了提高地址计算的效率，用直接定址法来构造哈希函数，采用链地址法来处理冲突。首先根据初始的数据确定哈希表的长度，一般情况下为了减少冲突，可以生成一个空向量使该向量的长度大于初始数据的长度，然后由给定的哈希函数和冲突处理函数把相应的监控点类型或监控点的名称映射到向量的各个元素中。如果该向量表已经装满，只需要在该向量尾部中添加一个元素把新增的数据填充到该元素中，然后把该元素的下标放到链地址表中。 　　3．监控点参数的排序和检索。电网监控系统中每个监控点对应现场中的一个装置，所以监控点需要一些参数来反映该装置的状态，一般情况下，监控点的参数个数都不会太多。根据顺序存储和顺序检索在数据量比较少时，效率比较高的特点，采取顺序存储和顺序检索的方法来实现。并且根据检索频率来动态调整参数的位置，使检索频率高的参数位于向量的前部，检索频率低的参数位于向量的后部。 4．多线程技术的引入 　　在电网监控系统中，实时数据库系统要实现现场的数据实时的更新，能够根据现场的数据进行安全监视、现场模拟，对现场的数据根据用户的设置的时间间隔进行保存，发生事故的监控点进行事故追忆等。如果这些功能全部由一个线程来完成，会因资源冲突等问题而影响处理效率。为此，我们采用了图2所示的多线程结构。整个系统有通信线程、报警处理线程、写历史库线程、写磁盘线程、显示监控线程和主界面线程组成。 通信线程主要负责实时数据库和现场的通信。现场的各个测控装置把采集来的数据送到各个端口，通信线程实时的扫描各个端口，通过各种规约转换把现场采集来的生数据转换为系统或用户能够理解的熟数据送到实时数据库中，必要时把生数据也一同送到实时数据库中，同时接受显示监控线程传来的各种控制和调节命令，并通过相应的通信规约转换为测控装置能够识别的数据，送到底层装置中去执行。通信线程还负责把需要保存的现场生数据、通信模块的系统信息和故障信息写入一缓冲区队列中，交由另一线程来处理。 　　报警处理线程主要负责数据库的实时扫描、报警和事故的判断和处理。该线程由通信线程触发，处理过程由图3报警处理流程图所示，当有数据写入实时数据库时就触发该线程。为了防止报警和事故事件的遗漏，用全局变量 NoProccessCount来记录在一个实时数据库的扫描周期中现场值已经改变但未被处理的点数，用来bNew标志该点的现场值在该扫描周期中是否被改变。当通信线程写实时数据库时，置相应点的bNew标志为改变状态，并把 NoProccessCount增1。当报警处理线程触发后，首先在实时库中查找到该点， 使NoProccessCount减1，置bNew为未改变状态，进行报警和事故判断。如果发生报警或事故则进行相应的处理，并把报警信息或事故追忆值写入相应的缓冲区队列中，由另一线程来处理。然后判断NoProccessCount是否为０。如果为０表示实时数据库中没有要处理的点，该线程等待直到下一次被触发。否则扫描下一个监控点，判断该点的bNew是否处于改变状态。若是，使bNew设为未改变状态，NoProccessCount减1，进行报警和事故判断。如果发生报警和事故进行相应的处理，然后判断NoProccessCount的值。循环执行以上步骤，直到被结束事件触发，该线程结束。 　　写历史库线程主要负责把实时数据库中的数据定时地保存到外存数据库中。在电网监控系统中，允许用户自定义历史库数据，即用户可以定义要保存的状态变化量和测量值以及保存的时间间隔。在实现时为提高效率，我们将所有需要保存历史数据的监控点信息构成一个链表，在该链表中历史库接点的结构为： struct HistoryNode{ string stationName; string typeName; string pointName; time_t startTime; double intervalTime; struct HistoryNode *next; } ; 其中：stationName为该点的厂站名称，typeName 为该点的类型，pointName为该点的名称，startTime为上一次存入历史库的时间，intervalTime为写入历史库的时间间隔。写历史库线程实时对链表进行扫描，方法是：对链表中的每一个点，首先取系统时间与startTime比较，如果系统时间和startTime之差大于intervalTime，说明该点的写历史库周期已到，这时由stationName、typeName、pointName构成索引在检索实时数据库，得到该点的值，并将其写入相应缓冲区队列中，然后由写磁盘线程写入外存数据库，否则扫描下一个节点。 　　显示监控线程主要负责现场实时模拟和现场控制。现场中的每个点在模拟画面中都有相应的映像，该线程定时扫描画面中每个映像点，根据映像点的厂站名称、监控点类型、监控点名称查找实时数据库，得到该模拟点的值，并根据该值来改变画面上模拟点的状态或显示该值。 　　主界面线程主要负责用户的在线设置工作。该线程把用户自定义的一些信息如历史库数据定义、报警允许定义、报警上下限定义等写入实时数据库中。同时还负责各种线程的管理工作。 写磁盘线程主要负责把缓冲区队列中的数据写入外存，对于缓冲区队列的读写引入了生产者—消费者模型，参见图4。在该模型中分别有一个生产者（RP）和一个消费者（WP）两个缓存池，其中通信进程、报警处理线程、写历史库线程为生产者，写磁盘线程为消费者，同一时刻对同一个缓存池的生产者和消费者要互斥地访问。开始时，由生产者即通信进程、报警处理线程、写历史库线程其中之一，负责先将两个缓存池都充满，当两个缓存池都写满后，如果系统中还有新产生的数据，则扩大第二个缓冲池。然后把第一个缓冲池交给写磁盘线程，并通知它可以读取数据了，这是写磁盘线程开始把第一个缓冲池的数据写入外存中。当写磁盘线程读完一个缓存池后，把该缓冲池交给生产者线程，并通知生产者线程，该缓存池已空可以继续接收数据了，然后，等待第二个缓冲池可读时把该缓冲池中的数据写入外存。这样轮流的进行读写，使得通信进程、报警处理线程、写历史库线程对数据的操作都是在内存中进行，可以大大提高处理的效率。 整个系统通过各个线程之间的相互协调来工作，各线程之间利用事件来触发，可以避免因循环检测而浪费系统效率。 5．结束语 　　与现存的实时数据库的检索方法相比，本文提出的两种方法在减小表的平均查找长度和提高数据处理的速度方面取得了较好的效果。例如在文献【15】和【16】中实时数据库的存储形式采用的是Ｂ-树结构和顺序结构。假定实时数据库中数据项的个数为n，平均查找长度ASL。采<